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Purpose 

To  present  results  of  an  SEI  IR&D  project  dealing  with 
system  of  systems  interoperability.  We  wanted  to: 

•  Identify  critical  interoperability  issues 

•  Gain  insight  into  programs  that  are  solving  critical 
problems 

•  Develop  recommendations  for  future  research 
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SOSI  Motivation 

Interoperability  between  systems  has  become  increasingly 
important  -  no  modern  system  stands  alone. 

•  Future  Combat  System 

•  Air  Operations  Center 

•  Navy  battle  groups 

•  Joint  battle  forces 

Improved  interoperation  will  not  happen  by  accident. 
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Approach 

This  work  included 

•  Development  of  a  model  for  interoperability. 

•  Workshops  with  an  expert  advisory  panel. 

•  Selected  interviews. 

•  Literature  review. 

Emphasis  is  on  problem  setting,  not  problem  solving. 
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Defining  Interoperability 

Lots  of  definitions  are  available,  and  involve  different 
views,  e.g., 

“The  ability  of  systems  to  work  together.” 

“The  ability  of  systems  to  exchange  and  use  services.” 
Ours: 

“The  degree  to  which  a  set  of  communicating  entities 
are  (i)  able  to  exchange  specified  state  data,  and  (ii) 
operate  on  that  state  data  according  to  a  specified, 
agreed  to,  operational  semantics.” 
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Life  in  the  Real  World  - 1 

A  program  was  building  a  large,  distributed  combat  system. 
They  were  integrating  many  subsystems,  many  provided 
by  other  programs.  As  part  of  their  system  test,  they 
require  a  simulator,  which  was  developed  by  yet  another 
program. 

Funny,  but  the  simulator  was  late.  When  it  arrived  the 
simulator  did  not  implement  the  interface  as  expected. 

Should  we  be  surprised  when  things  started  going  wrong? 
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Life  in  the  Real  World  -  2 

Two  systems  were  being  built  using  industry  standard 
object  request  brokers  provided  by  different  COTS 
vendors.  The  program  offices  assumed  conformance  to  an 
industry  standard  implied  interoperability.  Turned  out,  one 
vendor  added  unique  features  that  extended  the  standard. 

When  the  systems  were  tested  they  did  not  interoperate 
as  planned.  Why? 
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Life  in  the  Real  World  -  3 

Multiple  combat  systems  are  exchanging  data  over 
different  communication  links.  Each  type  of  link  is 
ultimately  based  on  a  data  model,  with  its  own  idea  of  the 
meaning  of  things.  So  different  users  can  get  different 
views  of  the  battle  space. 

How  can  users  be  wholly  confident  in  the  information  that 
they  are  receiving?  How  do  they  resolve  conflicts? 
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Models 

Models  provide  a  context  for  discussion  and 
understanding. 

Several  models  for  interoperability  exist,  e.g., 

•  Levels  of  Conceptual  Interoperability  Model 

•  Levels  of  Information  System  Interoperability  (LISI) 

•  NATO  Reference  Model  for  Interoperability 

•  Organizational  Interoperability  Maturity  Model 

These  models  focus  on  technical  or  operational  aspects  of 
a  system. 


Carnegie  Mellon 

Software  Engineering  Institute 


SOSI  Model  View 

Our  focus  includes  the  programmatic  aspects  related  to 
interoperability.  This  extends  other  interoperability  models. 
We  suggest  the  term  programmatic  interoperability. 

The  SOSI  model  addresses 

•  activities 

•  organizations 
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Activities 


Program 

Management 


System 

Construction 


System 

Operation 


Activities  performed  to  manage  the 
acquisition  of  a  system. 


Activities  performed  to  create  a 
system.  Focus  is  on  architecture, 
standards,  COTS. 


Activities  performed  to  operate  a 
system.  Focus  is  on  interactions  with 
other  systems,  and  data  distribution. 
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SOSI  Model 
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Widening  the  Context 
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Summary  of  Results 

Leadership  &  Policy 
Vision 

Funding  &  Control 
Motivation  &  Incentives 
Requirements 
Contractor  Processes 
Technology  &  Architecture 
Standards 

Legacy  and  Evolution 

Remember,  we  still  acquire  systems,  not  capabilities. 
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Leadership  &  Policy 

Policies  are  insufficient.  They  are  often  rigid  and  reflect 
only  one  domain.  What  evidence  is  there  for  their  success? 
Are  there  metrics? 

A  barrier  to  interoperability  is  a  lack  of  centralized  or 
coordinated  ownership  of  the  problem.  Policies  don't  reach 
down  far  enough. 

Short-sighted  decisions  promote  a  single  system  view  at 
the  expense  of  other  systems. 


Remember  the  golden  rule. 
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There  are  grand  plans.  But  insufficient  understanding  of 
what  the  services  are  trying  to  achieve. 

Solutions  can  often  be  local  in  scope,  and  inconsistent 
with  higher  vision. 

Should  the  approach  for  the  vision  be  top-down  or  bottom- 
up?  Do  we  know  enough  to  ask  the  right  questions  and  to 
answer  them? 


Where’s  the  belly  button?  How  many  are  there? 
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Funding  &  Control 

Interoperability  is  insufficiently  funded,  and  reaching 
agreement  with  other  programs  depends  on  money. 

There  are  funding  and  control  limitations.  Loss  of  control 
can  be  frightening. 

PMO  staff  is  often  inexperienced  in  estimating  costs  for 
interoperability. 


Interoperability  must  be  planned  and  resourced 
appropriately.  How  much  of  the  overall  funding  model 
needs  to  change? 
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Motivation  &  Incentives 

There  is  limited  motivation  to  provide  an  interoperable 
system.  The  real  motivation  is  to  produce  the  system. 

No  one  wants  to  spend  the  money  to  make  interoperability 
work. 

We  need  better  incentives.  Incentives  are  program 
oriented,  not  in  the  context  of  how  the  system  will  be  used 
with  other  systems. 

Cross-program  management  is  ad  hoc  or  missing. 


It  comes  down  to  a  big  stick  and  money. 
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Requirements 

Until  recently,  few  interoperability  requirements  were 
identified.  Interoperability  often  came  about  when  the 
system  was  deployed. 

Requirements  across  multiple  systems  can  lead  to  sub- 
optimal  solutions  for  any  one  system.  Not  mine! 

The  first  thing  that  goes  when  things  get  tight  is 
interoperability  with  non-critical  systems. 

Organizations  are  struggling  with  Information  Exchange 
Requirements  in  a  net-centric  environment. 


Requirements  must  interoperate  also. 
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Contractor  Processes 

Interoperability  can  be  hindered  by  size  and  diversity  of 
systems  and  number  of  necessary  contractors. 

Few  processes  that  allow  contractors  to  work  as  peers  to 
achieve  interoperability. 

Large  cast  of  characters  trying  to  provide  solutions. 


Interoperability  requires  a  full  service  approach. 
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Technology  &  Architecture 

At  the  management  level,  most  believe  that  technology  is 
not  the  problem,  e.g.,  XML  is  a  solution.  The  market  has 
converged  on  data  transmission  standards. 

But  some  elements  are  missing  (e.g.,  joint  risk 
management,  real-time). 

Current  architectures  provide  insufficient  information  to 
achieve  interoperability. 

There  is  a  lack  of  a  system  of  systems  architecture,  and  it 
is  needed. 


What  do  we  really  need? 
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Standards 

Use  of  standards  gives  a  false  sense  of  security. 

Standards  are  often  inconsistent  and  not  fully  specified. 

Who  selects  standards  can  have  major  implications  in  a 
performance-based  environment. 

Standards  bodies  have  a  built-in  tension  due  to 
constituency. 

Certification  processes  can  be  passed;  systems  fail  but 
are  deployed  anyway. 


Standards  are  necessary  but  not  sufficient. 
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Legacy  &  Evolution 

Backward  compatibility  is  an  issue  since  there  is  never 
enough  to  upgrade  all  systems.  This  can  limit 
interoperability  with  new  systems. 

Interoperability  can  degrade  over  time. 

We  need  more  of  a  lifecycle  focus,  including  training  and 
simulation. 


Today’s  system  is  tomorrow’s  legacy. 
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Signs  of  Progress 

DoD  Interoperability  Initiatives 

•  Commands,  Directorates,  and  Centers  (14)  e.g.,  DISA 
Interoperability  Directorate 

•  Standards  (3)  e.g.,  DoDAF  Architecture  Framework 

•  Strategies  (4)  e.g.,  Global  Information  Grid  (GIG) 

•  Demonstrations,  exercises  and  test  beds  (4)  e.g.,  Joint 
Distributed  Engineering  Plant  (JDEP) 

•  Joint  and  Coalition  Force  initiatives  (19)  e.g.,  Single 
Integrated  Air  Picture  (SIAP) 

•  DoD  sponsored  research  e.g.,  DARPA 


24 


Carnegie  Mellon 

Software  Engineering  Institute 


The  Nature  of  the  Progress 

There  is  clear  understanding  of  the  importance  of  the 
problem,  although  solutions  are  not  yet  aligned. 

Some  organizational  restructuring  has  been  done,  e.g., 
JFCOM. 

Resources  are  now  being  dedicated  to  finding  solutions. 

Some  solution  approaches  are  being  implemented  and 
appear  promising,  e.g.,  Army  Blocking  Policy,  Air  Force 
C2  Constellation,  SIAP. 
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There  is  More  to  Do 

We  see  a  need  for 

•  identification  of  barriers  to  programmatic  interoperability. 

•  mechanisms  to  improve  programmatic  interoperability 
(e.g.,  joint  risk  management,  assessment  instruments, 
interlocking  award  fees,  experience  sharing). 

•  understanding  implications  of  network-centric  systems 
for  interoperability  and  emergent,  unbounded  behavior. 

•  understanding  effects  of  component  architectures  on 
quality  attributes  (e.g.,  performance,  etc.)  in  large  context. 

•  approaches  for  legacy  system  integration  and  migration. 

•  an  understanding  of  the  basic  theory. 
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Summary 

The  SOSI  work  has  begun  to  explore  the  subject  of 
interoperability — problems  and  solutions. 

The  work  is  continuing  under  the  Integrated  System  of 
Systems  (ISIS)  initiative  at  the  SEI. 
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Reports 

The  SOSI  work  is  described  in  two  reports  (available  on 
the  SEI  website): 

Linda  Levine,  B.  Craig  Meyers,  Ed  Morris,  Patrick  R. 
H.  Place,  and  Daniel  Plakosh,  “Proceedings  of  the  System 
of  Systems  Interoperability  Workshop  (February  2003)”, 
SEI  TN-016,  June  2003. 

Linda  Levine,  B.  Craig  Meyers,  Ed  Morris,  Patrick  R. 
H.  Place,  and  Daniel  Plakosh,  “System  of  Systems 
Interoperability:  Final  Report  SEI  TR-004,  2004. 
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